#2178: Make Release commandlet build-tool independent - #2302

Thanks for picking this up 👍 — and thanks especially for not stopping at the literal ask. Turning the detection loop from last match wins into first match wins (BuildCommandlet#findBuildCommandlet) quietly fixes two real bugs that were sitting in BuildCommandlet:

• In a yarn project (package.json + yarn.lock) the old loop had no break, so after Yarn matched it kept going and Npm — last in BUILD_TOOLS — always took over. Yarn.findBuildDescriptor was effectively unreachable.
• Worse, in a polyglot repo (pom.xml and package.json) the old code ran npm but resolved the defaults from MVN_BUILD_OPTS, i.e. it executed npm clean install. Hoisting the args.isEmpty() block out of the loop fixes that too.

Also good: the parent == null guard in isTopLevelProject — the old projectPath.getParent().resolve("pom.xml") would have thrown a raw NPE when releasing from a filesystem root.

No blockers. The instanceof BuildTool gate is the right shape, CliException is the correct exception type here (expected, user-facing abort), no public signature was broken, and the tests stay inside target. A few things I'd like to see before merge:

Should-fix

1. ReleaseCommandlet:45-48 — the error message collapses "no build descriptor at all" and "build tool found but it cannot release" into one text. A Gradle user gets told nothing useful.
2. BuildCommandlet:73 — the new detection is a package-private static that ReleaseCommandlet reaches across into, and it takes an IdeContext parameter although both callers already have this.context. The issue itself points at the better home: "Ideally we should ask the commandlet manager".
3. BuildCommandlet:75 — findBuildCommandlet NPEs on a null path; BuildCommandlet guards before calling, ReleaseCommandlet does not.
4. BuildCommandletTest:142 — the yarn-over-npm fix is the user-visible part of this PR but is only covered at helper level; no test asserts that ide build in the yarn workspace actually runs yarn, and nothing covers the mvn-vs-npm precedence flip.

Minor

5. ReleaseCommandlet:106 — first condition is always true at the only call site.
6. ReleaseCommandlet:102 — parameter named buildTool but typed LocalToolCommandlet, while doRun has a different variable also called buildTool.
7. BuildCommandlet:55 — error message still hardcodes the descriptor list that this PR is de-hardcoding.
8. CHANGELOG.adoc:9 — the ide build precedence fix is user-facing and not mentioned.

PR hygiene

• The branch is BEHIND main and needs an update before merge.
• The checklist ticks "PR and issue(s) have suitable labels", but this PR carries no labels and no milestone. Per DoD.adoc both should be set before close (the issue itself is labelled fine).

Manual verification

Green CI is not sufficient for this one. ide release drives git commit/git tag/git push and a real deploy build — none of which the mock GitContextImplMock exercises end-to-end. Please do run your own testing instructions (2) and (3) on a real Maven project before merge, and note the result in the PR.

Scope against #2178: the primary ask ("ReleaseCommandlet should ask the available build commandlets if they apply") is met. The Additional context part — discovering build commandlets dynamically via the commandlet manager and expressing the yarn/npm priority without a hardcoded list — is not addressed; BUILD_TOOLS is untouched. That is explicitly framed as "ideally" in the issue, so I am not blocking on it, but please say in the PR whether you consider it out of scope so it can be tracked as a follow-up rather than silently dropped.

@laert-ll thanks for your PR. This looks great now and is ready for merge. 👍
I will create a follow up to prevent the typing and avoiding the casts.
Update: Done as #2420